Add warning regarding Unraid Gerbil WireGuard port #66
Conversation
|
Thanks for the PR! Is this always the case where you cant use 21820 on Unraid or was 51820 just occupied on your install? Wondering here if the port number itself is not the problem but just highlighting that the port in docker compose AND in the config needs to be the same which might be better suited for a different page in the docs. Thoughts? |
|
You can use the port on Unraid, it's just that the internal and external port in the Docker run command needs to be the same for Gerbil (hopefully can be patched). The port itself has no relevance, the only thing that matters in this case is that you use the (whatever provided by the Docker app) standard number. Once you click apply in the Unraid UI it will convert it to a Docker command internally (which is also shown to you, the user) So this will always work ports:
- ABC:ABC/udpThis will fail in Gerbil, XYZ being the custom external port ports:
- XYZ:ABC/udpSo this is also not entirely an Unraid issue, but it's an Issue that Unraid users cannot bypass unless we go change our Docker system to run as Template Authoring mode (theoretical, not tested), otherwise it's untweakable in the UI. |
|
Gotcha! Okay thanks will deploy! |
2 participants
Community Contribution License Agreement
By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.
Description
I have debugged an issue for 10-15 cumulative hours and I finally found the solution. The idea came to mind from reading this GitHub issue comment. Apparently the Gerbil Docker container internally does not like having different internal and external ports, it wants them to be matched.
I tried port
51820,51824,1194, all of them responded totcpdump -i any -n udp port [PORT]tests (confirming UDP packets were reaching the server when testing withecho "poke" | nc -u [IP] [PORT]), but I still had no Newt containers being able to connect.My
51822port was busy by another user on my network so that's why it took me so long to try the default setting, but once I did everything instantly worked.The issue was so obscure that even with great Discord support (thanks Astral), it was very hard to identify. For now, the earliest and easiest thing to do is at least notify any future user where an issue might occur, until it is hopefully fixed in the system itself later on.